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I. INTRODUCTION 



In America, "No natural boundary seems to be set to the efforts of man; and in his 
eyes what is not yet done is only what he has not yet attempted to do." 

Alexis de Tocqueville 

A. PURPOSE 

This thesis was produced with the objective of illustrating an innovative method for the 
tracking of interface relationships and cost tradeoffs in a midsized research and 
development program. The Sea Launch and Recovery System (SEALAR) was selected to 
be modeled because it is presently in the early stages of development and is the type of 
program which readily lends itself to be analyzed via a multimedia type database, in this 
case, Machintosh HyperCard®- The overall objective is to focus the reader's attention on 
the method of presentation and the flexibility and potential of the program employed. 

The decision to use HyperCard, a trademark of Apple Computer Incorporated, was 
based upon several factors. Specifically, HyperCard’s object-oriented properties support 
ease of development, portability and reusability of modules. These characteristics are 
enhanced by the ability of HyperCard to link to modules within itself or to other programs. 
These aspects of the program will be discussed later. In addition, these same object- 
oriented capabilities provide the developer with a rapid, interactive prototype environment 
that greatly enhances debugging and ultimately results in a program that has significantly 
increased robustness over that offered in other conventional programming environments. 

HyperCard provides the developer with a significant degree of flexibility and power, 
and a rich set of development tools and options. When combined, these establish a degree 
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of compatibility and cognitive richness found in few other programing environments. The 
human factors engineering and human interface technology found within the Macintosh 
operating system have been extended into HyperCard. These features allow the developer 
to easily acquire, manipulate and import text, sound and graphics into HyperCard without 
data conversion. 

To demonstrate the viability of a multimedia data base employed in such an 
application, the SEALAR X-3 rocket was selected. Due to limited time and resources, this 
initial implementation was aimed primarily toward the prototype’s propulsion system. 
However, it must be noted that this program is not designed to demonstrate applicability of 
a specific function, rather its purpose is to validate the integration possibilities across the 
entire functional spectrum of the SEALAR program. 

B. STRUCTURE 

The thesis is organized into five sections. The first section is essentially a political 
statement and assessment of where we are, how we got here, what avenues we are likely to 
pursue as a nation with regard to space utilization and exploration in the future, and what 
are the primary motivations and drivers of this process. 

The second section, background, contains a brief history of development of the water 
launch concept, including a summary of the Hydra and Sea Dragon projects completed in 
the early 60's, the ancestors of the SEALAR concept. 

Within the third section, programming environment, a brief overview is presented of 
the employment of HyperCard and an explanation of the object-oriented programming 
environment. It also includes a discussion of programming language features and 
capabilities. 
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The fourth section, application, the application, explains how the program was built 
and how to manipulate the stack and its numerous features. Within it is an explanation of 
the programs required to be installed on the computer in order to run the program and 
detailed instructions of how to operate it. 

Finally, the analysis and conclusion section gives an explanation of what the 
employment of HyperCard programming could offer a program like SEALAR in terms of 
the ability to track the interface relationships between components of both off-the-shelf and 
custom engineered components, and the unique ability to quickly and objectively compare 
specification and costing tradeoffs with minimal effort and reasonable reliability. 
Implementation issues are discussed and evaluated. Future enhancements to the program 
are also discussed. 

C. HISTORICAL PERSPECTIVE 

Man's inevitable quest for knowledge and adventure in the exploration and utilization 
of space cannot be satisfied solely by the use of machines and robots, as recently proposed 
by some scientists and members of Congress. This is not to say that robots cannot play 
important roles in helping define and shape the environments in which we will travel and 
live in the future, and in acting as sentinels carefully placed along the way in advance of 
manned missions. However, in order to make these dreams of today a reality tomorrow, 
we require a system offering reliable and cost effective access to space. 

In historical perspective, machines have never been used solely for the exploration of 
the earth and its many environments. Whether the objective was the conquest of the outer 
reaches of the atmosphere or the vast depths beneath the surface of the world's oceans, 
machines might have gotten there first but men were never far behind. Machines lack the 
innate ability to comprehend the unknown, i.e., they can only inform us about physical 
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quantities that we already are aware of. Of course they can quantify and analyze these 
known parameters more accurately and efficiently than a human. Therein lies both their 
utility and primary limitation. The conquest of space must be made by manned vehicles in 
conjunction with unmanned space probes. 

We humans have made great strides in our initial exploration of space: the Apollo 
program, landing the first man on the Lunar surface and returning him safely to the earth; 
the Soyuz program, having a man spend 237 continuous days in space; and the Voyager 
program, a pair of unmanned space probes which explored the outer planets of our solar 
system, to name only a few. However, when compared to the timeline of aviation, which 
in many respects, was a similar development process, we find that space exploration is 
indeed still very young. Aviation had its beginnings with the Wright brothers first flight at 
Kitty Hawk, North Carolina in 1904. In comparison the first terrestrial instrument or 
probe, Sputnik, was placed in orbit in October 1957 by the Soviet Union, 34 years ago. 
Employing some simple arithmetic we find that if we add this figure to aviation's birth date 
of 1904, the result is 1938. Clearly, aviation was undergoing rapid advances at this point, 
but was still very young, with many highly significant improvements to be made in the next 
53 years to bring us to the present. Thus it can be said with some confidence that space 
exploration is still in its infancy. 

There is, however, one singular difference between the development of aviation as an 
industry and space as an industry. The development of the aviation industry, to a great 
extent, was performed by individuals and companies and was financed substantially with 
funds derived from the private sector. Even given the increased military importance 
attributed to aviation in the post WW I era, the private sector was to be the motivating force 
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that was to keep aviation moving forward. The military, up until the beginning of WW II, 
had not begun a credible and substantial development program for the sole purpose of 
developing military aircraft. 

The above occurred because of several reasons. One was the relatively low cost of 
initial development of the airplane. The Wright brothers spent relatively little capital and a 
substantial amount of time in constructing their first aircraft. Another was the excitement 
and thrill of breaking records, of being the fastest or having flown the highest. During the 
20's and 30's, individuals seeking to make substantial contributions to an infant industry 
were eager and willing to risk resources, time and, in some cases, even their lives. These 
achievements were recognized by numerous awards and trophies on both sides of the 
Atlantic and were given with increasing regularity in the early to mid 20th century. Last, 
and perhaps the most important, was the fact that enterprising individuals and companies 
with foresight and vision recognized the potential for realizing a profit from an initial 
investment. 

In contrast, the development of the space industry has been, to a great extent, left in 
the hands of governments. The two primary reasons for this include, one, the relatively 
rapid realization by the military establishments of the world of the tactical and strategic 
applications of space vehicles and hardware, and two, the substantial cost required to 
develop, build, and launch space vehicles and hence to support a viable space program. 
While these reasons seemed valid and consistent for several decades, the paradigm in the 
early 90's now has begun to change. The world community has now largely 
acknowledged by consensus the end of the Cold War between the two superpowers. The 
American public has voiced increasing demands upon the US government to significantly 
reduce deficit spending and to increase support and funding for domestic programs. In the 
case of the Soviet Union, its public demands the substantial reform of the bureaucratic form 
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of government, a reversal of the trend of deterioration of their already stagnant economy, 
and a move toward an open market system interacting freely with Europe and the West. 

As a direct result of the above factors, the trend is toward a reduction of the 
governmental control and subsidization of the space industry within the United States and 
the Soviet Union. This ultimately means that once again the private sector must be 
encouraged to bear the burden and take the required risks if we are to continue to explore 
and develop our understanding of space. However, because of the tremendous cost 
involved, this cannot happen of its own accord. The governments, endorsed by bold and 
strong political leaders of the world, must support and nurture this fledgling industry, at 
least until it gains sufficient momentum and becomes a going enterprise, i.e., until it 
becomes profitable. In retrospect, had H. G. Wells fictional Baltimore Gun Club been a 
reality, and if its visionary members possessed the enormous capital required to develop 
and test a space vehicle, the world could have been vastly different today. 

As the decade of the nineties begins and we look toward the 21st century several 
important trends become evident. One, economies around the world are being restructured, 
primarily as a result of failed ideologies and of excessive deficit spending, both factors 
ultimately resulting in recession and economic stagnation. These realities will presumably 
lead to an altered global power structure based upon economics rather than strictly military 
prowess and might World leaders will increasingly be compelled to recognize that in 
conjunction with this power comes the burden of accountability. While U.S. leaders have 
to some degree had to deal with this factor in recent years, other world leaders will find this 
a new and often annoying challenge. As a direct result of technological advances in the 
field of communications and travel in the last twenty years, news events and advertising 
have developed an informed and educated public and constituency. World leaders will be 
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increasingly held accountable for their actions and decisions, many of which may well have 
long term effects upon our global environment, as well as short term impacts upon regional 
economies. 

Another important trend of the 90's will involve space. Its exploration, exploitation, 
and conquest will ultimately become dominant factors in defining our future and will hold 
the keys to our destiny. The realities of this statement will become increasingly evident as 
the decade unfolds. The earth provides only limited and inequitably distributed resources 
upon and beneath its surface. Scientists and environmentalists now acknowledge the 
perceptible and increasingly evident deterioration in the quality of our air and water. This 
sequence of disturbing events is occurring primarily as a result of the increasingly rapid 
exploitation and utilization of these finite resources. In the not so distant future, the use of 
extraterrestrial sources of power and raw materials may be not only economically prudent 
and advantageous, but the ultimate survival of the human species might well come to 
depend upon it. 

The rules and paradigms have changed with regard to advancing technology and space 
exploration. Where deficit spending was the norm in the late 70's and 80's, and where 
excessive funding was ultimately available when required and not an insurmountable 
problem, the systems designed and built to date largely reflect this fundamentally flawed 
policy. Now, largely because of economic necessity and the lack of strong public support, 
we are compelled to rethink and redesign our programs, systems and hardware and attempt 
to achieve previously established goals within this now constrained economic environment. 

As we plan, develop and prepare to launch our third generation earth sensing platforms 
and space probes, it is very likely that they will be significantly different from their 
predecessors in several aspects: they will be the result of significantly more international 
cooperation and funding; they will reflect the economic conditions and realities within 
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which they were conceived; they will likely be smaller and lighter, and inasmuch as 
possible be multifunctional in their capabilities. Additionally, they will be placed into space 
by a new generation of cost effective launch vehicles. 

With the question of cost ultimately driving the whole issue of how and with what 
vigor a space program is to be pursued, it becomes evident that the major factors that drive 
cost must be fully understood and optimized. This question is not new. During the last of 
the Apollo missions in the early 1970’s, forward looking individuals and planners had 
recognized that fiscal constraints would increasingly affect the U.S. space program. In the 
following excerpt from a Navy Space Systems Activity report, the answer to the cost 
dilemma was as follows: 

The existing launch systems are very expensive to operate because their hardware is 
completely expended during each single mission - the present cost per pound of payload 
delivered to low Earth orbit is on the order of $800 to $1000 (FY 73). Economic 
considerations demand, and the experience gained during the first fifteen years of space 
flight makes it possible, to develop a reusable Space Transportation System for a 
vigorous continuation of space exploration during the next decade and beyond. 

The development of the reusable Space Transportation System signals the end of 
the initial "brute force" period. Space flight operations will become to a large degree 
routine, like those of intercontinental airlines. Payload delivery costs to low Earth orbit 
will be reduced by the Space Shuttle to about $150 per pound initially, and later to about 
$100 per pound. The tremendous impact of the new Space Transportation System on 
Ground Operations including Range Safety, Communication, Reentry, Recovery and 
Retrieval will also be significantly rcduced.[Ref. 1] 

While the motivation and intent of the Space Shuttle concept was undisputably in the 
right direction, several elements ultimately leading to the failure to reach its cost objectives 
should be discussed. The Space Shuttle from its conception was to be a man-rated system. 
This factor in and of itself required extraordinarily high reliability, one of the primary cost 
drivers of such a space system. Secondly, the employment of numerous leading edge 
technologies throughout the system, some of which were not even through the research and 
development stage at its conception, contributed great uncertainty and unforeseen 
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technological challenges, ultimately leading to a significantly higher than estimated final 
system cost. Lastly, the cost of direct support, turnaround and refurbishment, and 
bureaucratic support were not accurately estimated nor maintained within reasonable 
bounds. "The Space Shuttle system has ended up being extremely expensive to maintain 
and launch. "[Ref. 2] 

By the mid 1980s, when the bills began to arrive in Congress, inquiring minds wanted 
to know if there was a better, more cost efficient system. Specifically, the House 
Committee on Science, Space, and Technology, and the Senate Committee on Commerce, 
Science, and Transportation requested and funded an assessment of available space 
transportation technologies. The broad realization was clearly that: 

. . . low-cost transportation is one of the keys to more efficient exploration and 
exploitation of outer space. If space transportation costs were much lower, 
government agencies and private firms with good ideas for using the space 
environment might be more willing to risk their investment capital.[Ref. 3] 

One plausible option was a concept which had been around for many years, and was 
in fact originally proposed by German missile engineers at Peenemiinde, toward the 
conclusion of World War II. They proposed enclosing a V-2 rocket in a large cannister and 
launching it out of the water in a vertical position. Following the war, the U.S. Naval 
Missile Center at Point Mugu, California continued research in this area under the name 
"Project Hydra". The stated policy of such research was "to develop vertical floating 
launch technology, and to apply it to both long-range missiles and satellite boosters". When 
the project was canceled in 1965, "it was generally conceded that the feasibility of this type 
of launch has been proven".[Ref. 4] 

Ultimately, in order to realistically fulfill mankind's needs and desires, a reliable 
cost effective system is required for placing materials and supplies into space. Only 
then will man be able to continue to explore the universe and to discover what is on the 
next planet or beyond the next star. 
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II. CONCEPT AND DEVELOPMENTAL HISTORY 



The decade of the 60's was perhaps the most exciting for space exploration and 
development to date. The decade began with the American and Russian space programs 
attempting to outclass one another in the "space race." With the lead position in serious 
doubt, the recently elected Democratic President, John F. Kennedy, "instructed his Vice 
President, Lyndon B. Johnson, to work with National Aeronautics and Space 
Administration (NASA) and seek out ways by which the United States could overtake the 
Soviet Union and demonstrate a superior American technology in full view of every nation 
on Earth. The ambitious goal would need dedication to objectives which would 
demonstrate a clear cut lead for the United States. It was decided that only a manned 
landing on the surface of the Moon was sufficiently in advance of contemporary Soviet 
accomplishments to give the space agency a fighting chance of getting there before the 
Russians."[Ref. 5] 

Consequently, on 25 May 1961, President Kennedy went before Congress and called 
for a massive new commitment to space exploration: "Now is the time to take longer 
strides - time for a great new American enterprise - time for this nation to take a clearly 
leading role in space achievement, which in many ways may hold the key to our future 
Earth. I believe that this nation should commit itself to achieving the goal, before this 
decade is out, of landing a man on the Moon and returning him safely to the Earth. No 
single space project in this period will be more impressive to mankind, or more important 
for the long range exploration of space; and none will be so difficult or expensive to 
accomplish." [Ref. 5] 



During this period 

NASA was rife with optimism. The Apollo program had been authorized, and the 
entire country was excited about space. It was felt that a manned space station, a 
manned lunar base, or a manned mission to Mars would follow hard on the heels of 
Apollo. It was recognized, however, that not all of these missions, perhaps none of 
them, could be achieved unless the cost of transportation from earth to low orbit could 
be drastically reduced. "[Ref. 6] 

It was during this decade that two unique concepts were to be partially developed, which 
some 35 years later would provide the basis and conceptual foundations for the SEALAR 
program. 

During the early 60’s a U.S. Navy research team at the Naval Missile Center, Point 
Mugu, California, proposed development of techniques for launching large solid-propellant 
rockets from the ocean. The project, headed by Lieutenant Commanders John E. Dr aim 
and Charles E. Stalzer, came to be known as "Project Hydra." The initial concept was to 
attack directly the deficiencies of land-based launch and support facilities. Throughout the 
life of the project, "approximately sixty successful launches of rocket simulators and actual 
rockets confirmed the feasibility of the basic launch method— floating the rocket vertically 
and exhausting gases directly into the water. Shapes ranging from 3 feet to 105 feet in 
length, and weights of 20 pounds to more than 10 tons, have been successfully launched in 
this manner." [Ref. 7] Most were constructed from surplus Department of Defense and 
NASA assets, requiring little modification and costing little or nothing to acquire. While 
most tests employed solid-propellant rockets, several storable liquid rockets were also 
launched successfully. 

The floating-launch concept was deceptively simple. Bare, unencapsulated rockets 
were waterproofed and made buoyant (through design or the addition of external 
floats). As the rocket motor built up to full thrust, the floating rocket rose vertically 
from its wet pad. Once clear of the water, it was indistinguishable from any land- 
launched rocket. Surprisingly, tests showed that the added upward force of buoyancy 
actually resulted in a performance benefit over land-launched missiles.[Ref. 8] 



Several important military advantages became readily apparent as the project 
progressed. The team found that any type of platform (i.e., ship, barge, submarine, etc.) 
was easily made capable of transporting and launching a rocket employing the Hydra, or 
vertical floating launch technique. Very large missiles could be handled with little more 
difficulty than was experienced with smaller ones. Finally, it was realized that an awesome 
concentration of firepower was possible, since any number of missiles could be launched 
simultaneously. 

As the Hydra Project progressed, the research team at Point Mugu proposed an 
ambitious and extensive development plan. Since it was determined that operational and 
technical problems would depend upon the specific size and mission of the vehicle 
produced, the team grouped the proposed vehicles into four classes. Figure 1 is reproduced 
from the "Hydra Program Plan"[Ref. 9] and depicts the class distinctions envisioned. It 
also illustrates the progress completed in reaching the denoted milestones. 
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SPACE VEHICLE AERO. STABILITY 




Within this figure is depicted a systematic approach to the development of a unique 
class of launch vehicles. Initially the prototype test vehicles, consisted largely of surplus 
and custom one of a kind rockets and missiles. The development of unguided suborbital 
probes followed, employing and refining the design features and elements derived from the 
previous test vehicles. They continued in complexity and development to the third class of 
suborbital guided probes and weapons. This process culminated into a class of orbital 
space vehicles, employing all of the features of the previous developmental stages and the 
same technology and construction principles. 

Despite a very long string of successful launches and an ambitious program plan, the 
Navy canceled the Hydra program in 1965. While documentation explaining the decision 
is not available, one can only assume that with the Vietnam conflict looming on the 
horizon, the Navy had more important commitments elsewhere. 

Also during this period, a retired Naval officer, Robert C. Truax, working as Director 
of Advanced Developments at the Aerojet-General Corporation, initiated an effort to 
discover the root causes of the high cost of space transportation and to formulate some 
principles for achieving more cost-effective designs. After collecting and examining all of 
the available data, his team reached the following conclusions: 

Costs vary only slowly with size, but very sharply with complexity, reliability, 
design margins, and "programmed invention." A large fraction of the cost of a space 
launch resided in the propulsion hardware that was thrown away. A low-cost launch 
vehicle, therefore, should be big, simple, reusable, not too reliable, and use existing 
state of the art technology wherever possible.[Ref 10] 

The Aerojet team went on to design a vehicle, which in their estimation, would be 
capable of fulfilling all foreseen mission requirements. Using accumulated data supplied 
from Marshall Space Flight Center (MSFC) and NASA, they devised a cost-optimized 
design based upon the principles previously described, making trade-offs largely 



intuitively, and in general, tending away from existing configurations. This resulting 
design was dubbed "Sea Dragon. "[Ref. 11] The economy of the "Sea Dragon" was 
obtained not through ever-increasing sophistication but through its great size, simplicity 
and reusability. [Ref 10] This prototype design embodied the characteristics deemed 
necessary for a low-cost launch vehicle: 

- It was big, 500 feet tall and 75 feet in diameter, and had a liftoff weight of 40 million 
pounds; it was capable of lifting to low earth orbit (LEO) nearly 1.1 million pounds 
of payload per flight. 

- It was simple; only two pressure-fed stages were used to attain LEO (300 nm). 
Each stage had only one main propulsion engine. Propellants used in the first stage 
were kerosene and liquid oxygen, in the second, liquid hydrogen and liquid oxygen. 

- It was reusable; the simplest and lightest means available to return the stages to earth 
were used: a parachute-like drag device on the first stage, and a heat shield plus drag 
device on the second. 

- It was sea launched; it was built in a drydock, towed to a lagoon, checked out 
dockside, fueled at sea, erected by flooding ballast, and launched directly out of the 
water. [Ref. 11] 

The report was submitted to NASA for review and scrutinization. Eventually, being 
skeptical because of its significantly lower predicted cost per pound to low earth orbit, 
NASA let a contract to Space Technology Laboratory (now TRW) to reevaluate and 
presumably discredit the Aerojet team's costing analysis. Surprisingly however, the results 
of this costing review largely supported the original study's estimations. 

Unfortunately, NASA funding began to decline after fiscal year 1964 and by the end 
of the decade was down from its peak of $ 5,350.8 million to $ 3,786 million in fiscal year 
1970. This factor, combined with the public's apparent disinterest in repeated Moon 
landings by the early 70's and the increase in spending required to fight the war in 
Vietnam, led to the termination of funding for new vehicle concepts by NASA. As a result 
the "Sea Dragon" studies were never pursued and explored. 
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Looking back, one can only wonder what systems might be in place today had these 
two apparently promising concepts been allowed to be developed fully. 

By the early 80's, numerous exercises, operational studies, and wargames had 
identified the requirements to proliferate and/or reconstitute space-based assets in times of 
crisis and in war. Most recently this need was demonstrated and validated in the Desert 
Shield and Desert Storm operations in the Middle East. This capability shortfall has led the 
Department of Defense to search for a low cost-per-pound to low earth orbit (LEO) space 
transportation system offering increased operational flexibility, redundancy, and 
responsiveness. Further, application of the concept could be realized within the 
commercial sector as a cost-competitive launch vehicle for industrial applications. 

The motivation to pursue the sea launch and recovery concept is not new, as 
previously alluded to. Additionally, the requirements supporting the development of such a 
concept are not singular in nature. It is of fundamental importance to understand both the 
motivation and requirements for a sea launch and recovery type vehicle. Only then, can 
one fully appreciate the importance and significance of developing SEALAR as a viable 
alternative and supplement to the assets presently available for placing both men and 
equipment into space. 

In 1986, DOD 5100.1 "Function of the Department of Defense and Its Major 
Components" described two functions of the Department of the Navy (DON): 

1) Develop in coordination with the other services, procedures and equipment 
employed by the Navy and Marine Corps forces in the conduct of space operations 

2) Provide sea-based launch and space support for the Department of Defense when 
directed 

The Secretary of the Navy opened discussion within the Navy in 1987 asking such 
questions as: "Will the technology work?" "Is the SEALAR concept advantageous to the 
Navy?" "How promising is the development of a sea-based launch platform?" 
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Consequently, the SEALAR program was initiated after gaining support from the Chief of 
Naval Research, Commander Naval Space Command, and Director of the Naval Center for 
Space Technology (NCST). NCST of the Naval Research Laboratory (NRL) has become 
the primary source for personnel and resources for the project. 

On the private sector side of the equation, Truax Engineering Inc. (TEI) submitted a 
proposal in response to the original NCST Broad Area Announcement which appeared in 
Commerce Business Daily on 25 August 1988. The proposal submitted included both 
analytical and experimental work which had been completed to date exclusively with private 
funds in support of the company’s goal of ultimately demonstrating the principles set forth 
in the original "Sea Dragon" proposal some 35 years ago. 

The Navy purchased the Truax Engineering prototype rocket, called the X-3, 
along with all associated ground support equipment for the fixed price of $750,000. 
Along with the rocket the Navy gained any patent rights or other intangibles associated 
with it and owned by Truax Engineering Inc., including the right to have the 
equipment or any portion of it reproduced by others without further 
compensation.[Ref. 12] 

The present SEALAR project is envisioned as the integration of the various design 
concepts which will ultimately lead to the development of a new family of simple, mobile 
and reusable space launch vehicles. These SEALAR launch vehicles portend to provide 
low cost and reliable access to space through the use of the following fundamental design 
concepts: 

- Low cost liquid propellants (LOX, Kerosene, LIE) 

Provides: Low cost, ease of handling 

- Two stages to Low Earth Orbit (LEO) design 

Provides: Simplicity, reliability and low cost 

- Single engine per stage 

Provides: Simplicity, reliability and low cost 

- Pressure fed engine design 

Provides: Simplicity, reliability and low cost 
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- Low chamber pressure engines 

Provides: Simplicity, reliability and low cost 

- Hydrogen dump cooling of large, low pressure thrust chambers 

Provides: Low weight penalty allowing larger payloads 

- Low cost high strength tanks, constructed employing conventional technology 

Provides: Simplicity, reliability, performance, and low cost 

- Global Positioning System (GPS) navigation 

Provides: Simplified logistics, reliability and low cost [Ref 13] 

Recently, Truax Engineering Inc., under the direction of the Naval Center for Space 
Technology and in conjunction with the Naval Research Laboratory have set up a 
comprehensive test plan. Initially, employing the X-3 rocket as the primary test vehicle, 
the test plan objectives include the verification of the design features of a water-launched 
vehicle, and multiple use and refurbishment characteristics. Also, through repeated 
launches and recoveries, experience can be provided from which more accurate estimates of 
turnaround costs may be made. 

Lastly, and perhaps most importantly, the following two tables (Tables 1 and 2) 
vividly illustrate the advantages and benefits of the SEALAR concept over that of 
conventional expendable launch vehicles. 
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COMPARISON OF SEALAR AND 
EXPENDABLE LAUNCH VEHICLE (ELV) 
CONCEPTS 

FACTORS UNIQUE TO SEA LAUNCH 
TABLE 1 



Earatpeter 


SEALAR 

Concept 


Conventional 

ELVs 


Launch Inclination 


Water Launch allows 
feasibility to match launch 
latitude to orbit inclination 
for optimization of payload 
performance 


Fixed US launch site 
locations, at roughly 40N 
latitude, result in payload 
performance reduction for 
low-inclination orbits 


Launch Rate 


The Water Launch Concept 
allows for an unconstrained 
launch rate 


Launch rate limited by pad 
availability (typically 4 
launches/year/pad) - could 
preclude high launch rate 
programs 


Launch Azimuth 


Unconstrained with Water 
Launch affording maximum 
mission performance 


Limited by ground 
overflight restrictions - 
required dog leg maneuvers 
reduce achievable 
performance and add 
complexity 


Launch Pad Refurbishment 


Water Launch results in 
minimal damage to launch 
support infrastructure, 
thereby reducing cost 


Extensive pad refurbishment 
required after each launch 
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COMPARISON OF SEALAR AND 
EXPENDABLE LAUNCH VEHICLE (ELV) 
CONCEPTS 

FACTORS NOT UNIQUE TO SEA LAUNCH 

TABLE 2 



Parameter 


SEALAR 

Congest 


Conventional 

ELVs 


Launch Reliability 


Ultra Conservative Design 
provides high confidence 
launch; may sacrifice some 
performance for reliability 


Emphasis on high 
performance with inherently 
complex, pump-fed engines 


Launch Vehicle Cost 


Conservative approach of 
simplicity over optimized 
performance minimizes cost 


Stress on high performance 
over simplicity results in 
high cost 


Launch Vehicle Stage Reuse 


Attractive cost savings 
possible through recoverable 
and reusable staging concept 


Expendable Launch Vehicle 
concepts, by definition 
preclude reuse, a potential 
cost savings 


Launch Support 
Infrastructure 


Building-block launch 
vehicle approach provides 
for common mission 
support facility 


Unique launch pads for each 
ELV type results in 
inefficient pad utilization and 
non standard logistic 
requirements 
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It appears that the development of the SEALAR technology will provide the U.S. 
Navy, as well as other government and commercial interests, a low-cost-per-pound space 
transportation system with increased responsiveness, survivability, capacity, flexibility, 
and operation availability. With such a space transportation system a reality, it will become 
possible to satisfy all of the present major space missions in an economic fashion, 
including Space Defense Initiative (SDI), the manned space station (Freedom), a manned 
Lunar base, and the Manned Mission to Mars. 
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m. THE PROGRAMMING ENVIRONMENT: HYPERCARD™ 



In this section the primary programming development tool, HyperCard/HyperTalk™, 
will be briefly described. The programming environment HyperCard was developed by 
Apple Computer® Incorporated. It is designed to run exclusively on the Macintosh™ 
family of computer hardware. It is now being marketed as an extension of the Macintosh 
operating system. The HyperCard, Version 2.0 edition, was used for the development of 
the program on which this thesis was based. 

HyperCard is an event-driven, object-oriented programming environment that is driven 
by messages to and from objects. Actions are initiated in response to events which then 
send a chain reaction of messages from one object to another. HyperCard, also contains a 
general purpose programming language called HyperTalk. This programming language 
provides tools for painting, editing functions and semiautomatic program development. 
HyperCard is truly a multi-media development system that affords the programmer the 
ability to rapidly and easily integrate graphics, text and audio into an object-oriented 
environment. 

The programmer interface with HyperCard is very intuitive and easily learned; this is 
true as well for the user. An individual with little or no programming background is able to 
create very professional looking programs without writing any code. At the other end of 
the spectrum, a experienced programmer is capable of creating powerful functions and 
commands written in other computer languages, which may not be presently available in 
the HyperTalk functions. HyperCard has proven to be a substantial labor saving 
developmental environment and has significantly extended the domain of software 
development 
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HyperCard uses the metaphor of a stack as an object that can hold both processes and 
data, and exists only in the context of a stack. It is important to point out that a HyperCard 
stack is uniquely different from the classical data structure, in that it can be accessed from 
top or bottom or anywhere in between. HyperCard supports development of stacks that 
allow data, which may be any combination of text, graphics and sound, to be stored, 
linked, searched and or viewed. This unique set of attributes provides for the basis of the 
multi-media database application. Information may readily be linked relationally within a 
stack or from one stack to another. HyperCard is clearly not a replacement for traditional 
databases. However, as a stand alone multi-media database development tool, HyperCard 
allows applications to be constructed in minutes that would require monumental effort in 
conventional programming language. 

Within the HyperCard programming environment there exist five pre-defined objects. 
They are buttons, fields, backgrounds, cards and stacks. All HyperCard objects are able to 
send and receive messages; have unique properties including script which is code 
associated with that particular object; and have a visible representation that may be turned 
on or off. A button is a specified area on a card that is accessible with the mouse pointer. 
Buttons may be graphical, textual, a combination of both or totally invisible. When the 
user clicks the mouse pointer on a button, a message will be sent to the button and the 
script of the button will be executed. A field is an area in which textual data is stored on a 
given card. Fields are not static. They may be adjusted to any desired size, shape or 
appearance. Field scripts, like all scripts in HyperCard, are also event driven. 
Backgrounds are objects that cards often times share to give the program a homogeneous 
look. Cards are the objects on which fields, buttons and backgrounds reside. A stack can 
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consist of only a few cards or several million depending upon the application. The stack, 
along with the objects it contains, cards, backgrounds, buttons and fields, and any attached 
outside resources, constitute the executable program. 

Modularity is a unique property of objects in HyperCard. Once created an object may 
be moved in its entirety to another stack with its graphical appearance, scripts and resources 
intact. This feature makes HyperCard particularly suitable for rapid prototype development 
and facilitates code reusability. 

Sending messages is an important characteristic of an object-oriented programming 
environment. HyperCard generates messages, called system messages, which are sent to 
objects in response to certain program events. This affords the programmer the ability to 
model real world data efficiently and accurately. It also permits the establishment of 
browse, search and reporting capabilities within a program. 

Whenever script is executed a message is generated. The first object to receive the 
message is the sending object and if it has a message handler (a subroutine in HyperTalk) it 
will execute the handler. The script can also call the same message handler from which the 
message originated. This is called recursion in HyperTalk. HyperTalk is also capable of 
nesting, which would occur if handler 1 in object A calls handler 2 also residing in object 
A. These capabilities allow the developer to create data structures similar to those found in 
conventional programming languages. 

Within HyperCard are found two types of objects: transparent and opaque. 
Transparent objects are virtually invisible, that is they allow the user to look down through 
layers of cards below the top layer. Opaque objects however are solid. Consequently, 
they block the user from observing objects directly below. Every HyperCard object is 
created in its own layer, the layers are placed one on top of the other as the objects get 
added to the stack. The layers perhaps can be best visualized as infinitely thin sheets of 
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clear plastic. Opaque objects are visible through all layers of the stack regardless of their 
relative stack position, that is unless they get covered by another opaque object in a 
subsequent layer which would render the lower object impossible to be seen by anyone 
looking down. Transparent objects allow the user to observe opaque objects below. 

Buttons, which are a type of HyperCard object, can be layered into a stack like any 
other object. Whether transparent or opaque, buttons will react to pointer mouse clicks 
regardless of depth in the layer. This is different from transparency, in that, when an 
object's visibility is set to false the object not only cannot be seen but is also deactivated. 
However, attributes of an object whose visibility is set to false may be obtained or changed 
through the use of the scripting language HyperTalk. Visibility and layering together 
provide the programmer with the ability to construct complex data structures and establish 
inheritance of code by layering buttons on top of one another and passing discrete 
commands from one layer to another. This is a very significant attribute in that it gready 
facilitates compactness and reusability of code. Specifically, the invisible button was 
essential for the development of the SEALAR program because it is by employing this 
feature that the user is able to define a pathway to a desired subsystem, component and 
piece or part. All that is required for the user is to click on a graphic representation and the 
program will respond by displaying a blowup of the selected graphic. 

The two categories of layers found in HyperCard are background and card. 
Everything assigned to a background is active and visible on every card of that same 
background in the stack, that is anything placed into a background design gets copied onto 
every other card with the same background: this includes graphics, text, and buttons. The 
programmer can choose to place graphics, text, or buttons onto a specific card and have 
them visible only when that particular card is the top card in the stack, by placing those 
objects into the card domain. All objects in the card domain are in the very top layers of the 
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slack with background objects lying below. The card domain can be thought of as a 
foreground. Conceptually, it is very important to note that card objects are visible and 
active only in their respective layers, whereas background objects are visible and active for 
all cards sharing a particular background. In terms of creating applications, this subtle 
difference between foreground cards and backgrounds becomes an indispensable tool for 
the programmer to hide certain action buttons from the user at different points of the 
program by covering up an action button on a background card with an opaque object on a 
foreground card. Background buttons can be created only one at a time, each in its own 
layer, however, the user can not discern any difference between the two buttons or the two 
layers because both opaque buttons are readily visible and show no obvious indications of 
being in two completely different layers. Careful manipulation of the background and card 
layers enables the programmer to develop a look and feel which results in a user friendly 
interface. This also allows for the modeling of complex data structures that are analogous 
to everyday metaphors. 

System protection for SEALAR is inherently important for the establishment of 
program and data integrity. This is easily supported by HyperCard in the form of its built 
in stack protection mechanism. Stack protection is provided by the system. The level of 
protection is determined by the programmer and is assigned via the "protect stack" menu 
which allows for the selection of virtually any level of protection desired. Passwords are 
available options that can be used to protect a particular stack. A more sophisticated level 
of protection exists by using the scripting language HyperTalk which allows the 
programmer to limit the data which may be accessed down to the data element level. This 
capability may be extended to password protection which can be applied to protect a 
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specific data element or specific function. By employing the scripting language HyperTalk 
a programmer has complete flexibility with regard to limiting users to specific functions and 
data elements. 

Another extremely important aspect of HyperCard is its linking ability. HyperCard 
links are a method of establishing a unidirectional pathway from one card to another. Links 
may be between cards in the same or different stacks regardless of either card's relative 
stack position. Bi-directional links can also be programmed by inserting a unidirectional 
button on each card such that each card has a pathway to the other. To establish links 
between cards in the same stack either the unique card identification number is used as a 
destination address or the card name can be used. Links to cards in different stacks are 
exactly the same with the addition of the new stack name to the destination address. 
HyperCard linking enables the programmer to implement true conceptual relational database 
applications, that is, data never needs to be duplicated and there is no data redundancy. 
This is accomplished by HyperCard's ability to create links via unique identification 
numbers that are independent of data content 

HyperTalk is a general purpose programming language that contains an extensive set 
of commands and functions. It is also a special purpose language that tends to be better for 
some programming tasks than most other languages, such as construction of visual 
databases and educational systems. It is a very intuitive and natural language which tends 
to favor nonprogrammers in its grammatical style. The object-oriented nature of HyperTalk 
makes the scripting portion of the programs compact, extremely easy to debug and very 
portable from one to the other. The finished programs tend to be very intuitive for the user 
to operate and have a visual look and feel that in other languages would be hard to achieve. 
This makes HyperTalk a very labor saving programming language. One of the most 
powerful features of HyperTalk are the external commands (XCMD’s) and external 
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functions (XFNC's) which allow virtual unlimited extendibility. When HyperTalk was 
created two interface capabilities were installed called XCMD and XFNC. These two 
items enable HyperTalk to search the resource fork of the stack for a command or function 
if it is not found with the stack script. This capability provides virtual unlimited 
extendibility to the HyperTalk language. HyperTalk will search the resource fork of the 
stack for an unknown command of the type XCMD and likewise will search for an 
unknown function of type XFNC for an unknown function. Therefore, when a 
programmer wishes to extend the language for HyperTalk, he can write a function or 
command in another language and move it into the resource of the stack where he wishes to 
use it. Consequently, extensions to the HyperTalk language are always carried with the 
individual stacks that require them. Selected commands and functions from a library of 
XCMD's and XFNCs are easily moved into and out of stacks as desired. 

The HyperTalk scripting language is totally unique among programming languages. 
Command structures are English like sentences or phrases such as "go to card 8613" or 
"set the user level to 5." HyperTalk is also very forgiving in syntax and it allows multiple 
variations in command structure. This is a very important distinction in terms of ease of 
programming, project implementation and project modification. 

Functions in HyperCard may be one of three types: HyperTalk defined, user defined, 
or XFNC. HyperTalk functions behave in the same fashion as conventional programming 
language functions. When a function is invoked in HyperTalk, the scripts are searched in a 
hierarchical fashion until a match is found. If it doesn't find a match then the resource fork 
is checked to determine if a XFNC is available. This method of determining function 
location allows the programmer to redefine system functions as well as define entirely new 
ones. The ability to redefine the environment proved very valuable as this program was 
built. While HyperTalk is powerful enough to handle most programing requirements, the 
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ability to write XCMD and XFNC in other languages is extremely useful. This capability 
allows discrete external functions and procedures to be executed from within a HyperCard 
stack. 

There are two sound commands available in HyperTalk, play and beep. Play requires 
a digitized type resource to be available in the stack for the voice parameter. The play 
command is used to play digitized sound or to play music form a string of notes. Beep is 
used to invoke the system beep. Another common sound command which is an XCMD is 
called "Talk." Talk, uses another program called MacinTalk™, which is a product of 
Apple Computer Incorporated. It converts text or phonemes into computer generated 
speech. Both digitized speech and "Talk" were utilized throughout the SEALAR program 
in an effort to appeal to the user's audio sense and to promote a friendly "look and feel." 

The most significant criticism of HyperCard is that its language HyperTalk is an 
interpretive language. In some applications this tends to degrade execution speed. This is 
offset, however, by HyperCard's rapid search and card selection rate. Another limitation is 
that, at present, HyperCard can only display one card on a black and white screen at a time. 
Some of these limitations have been remedied by the creation of handlers by individual 
programmers in the form of XFNC's and XCMD's and are available in the public domain. 
Presumably, future upgrades will be made available that will move HyperCard into the 
realm of color graphics and multi dimensional displays. These features will serve to make 
the challenges and options available to the programmer even more fascinating and 
interesting. 
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IV. APPLICATION AND IMPLEMENTATION 



As designed and implemented the SEALAR prototype is based upon a single graphical 
stack which allows the user to readily visualize images of the rocket system, subsystem, or 
component. The HyperCard program provides the user with a visible graphic interface, 
supplemented with audio descriptions, and coupled with a technical textual description 
thereby reducing the technical knowledge required to become proficient in using the 
program. 

The stack is constructed using modular design features. This aspect is of critical 
importance because it enables the software program to be dynamic and respond to frequent 
or periodic updates and revisions. By maintaining this modularity, changes can be 
implemented within one module with no adverse side effects to other modules within the 
program. 

The SEALAR prototype is entered at the subsystem level. The user is then asked to 
select one of seven modeled subsystems available for examination. This approach is in no 
way intended to be all inclusive or static, rather it is intended to represent a reasonable 
subsystem break down of the X-3 rocket modeled. Appendix A depicts the stack 
developed for the SEALAR prototype program. Conceptually, there would be seven 
virtual stacks, with one representing each subsystem. Within each subsystem’s virtual 
stack there would reside the actual individual component stacks. Quite literally, each 
component installed on the modeled rocket would have its own stack consisting of the 
myriad of subcomponents that make up the functional unit This serves to demonstrate the 
modularity feature referred to earlier. As design changes and modifications are 
contemplated or implemented, only the corresponding stacks need be updated, not the 
entire program. 
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The SEALAR prototype represents a multi-media database. Graphics are employed to 
represent objects that were historically represented by textual descriptors or attributes. In 
this program the textual information is used to enhance and expand the meaning of the 
object the user is currently viewing. Audio is additionally employed to enhance the 
intuitive environment. When viewed on the whole, the program provides a true multi-media 
presentation. 

The background buttons which appear on every card of the stack are an integral part of 
the look and feel of the SEALAR prototype. Examples of these background buttons 
include HELP, LIBRARY, SEARCH, etc. The HELP button allows the user to quickly 
refer to a system reference manual if disoriented while navigating through any portion of 
the system. The TECHMAN button gives the user instant access to the pertinent section of 
the "X-3 Technical Manual" [Ref. 13], that applies to the particular subsystem or 
component currently being viewed. A copy of this technical manual is included as 
Appendix C. The "Previous Card" button located in the upper right hand comer of every 
card enables the user to return to the previous card viewed and in this manner literally to 
back out of the graphical path just navigated. The rocket button located in the upper left 
hand comer of every card provides the user with the ability to immediately return to the 
beginning of the graphical hierarchy of the subsystem stack so that multiple subsystems or 
components can be investigated without having to exit and reenter the program. 

All graphic buttons are invisible so that they can be positioned over the various 
graphics found on each card. Special buttons are also utilized throughout this program. 
For example, the COST button instructs the HyperCard program to open a spreadsheet 
application in another program. In the case of the SEALAR prototype, the spreadsheet 
program employed was Microsoft® Excel, version 3.0. This program exhibited the 
capabilities to perform and display the required continuous costing computations and the 
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tracking of the changing interface relationships in an efficient and flexible manner. These 
features are demonstrated in the cost analysis of the propulsion subsystem included as 
Appendix D. It is in this manner that the component and subsystem costs and interface 
relationships can be tracked, evaluated and maintained. 

The HELP stack is an integral part of the entire program. It has been developed to 
provide the user with an intuitive look and feel that will answer any program specific 
questions that may arise at any level within the SEALAR prototype program. Help has a 
search function that eliminates the need to page through the entire stack to answer a single 
question and it fully defines the functionality of all background buttons. In addition to the 
functionalities described above, several scripts were employed to automate the development 
process. This capability significantly enhanced the development process and helped make 
the SEALAR prototype a reality. 

The graphics in the stack were scanned into a Macintosh 13® computer using a Hewlett 
Packard Scan Jet® scanner from reduced sized blue prints. The scanning program used 
was called Deskscan® version 1.0, developed by Zedcor Inc. The graphics were then 
imported and enhanced in a program called Deskpaint® version 1.05, also by Zedcor. 
They then were copied and pasted into Superpaint, a graphics program developed by 
Silicon Beach Software Inc. From this Superpaint file each graphic was brought into the 
HyperCard program and placed onto an individual card. These cards then comprise the 
SEALAR prototype stack. 

The SEALAR program can be run on any Macintosh Plus with 4 megabytes RAM 
internal and a 20 megabyte harddrive. The installed programs required on the computer 
include Macintalk, HyperCard version 2.0 and Microsoft Excel version 2.1. The final file 
sizes for the program were as follows: the HyperCard file was 433K, and the Microsoft 
Excel file was 17K. 
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V. ANALYSIS AND CONCLUSIONS 



This study indicates that it is indeed possible to develop a reliable and accurate system 
for the tracking of costs and interface relationships through the employment of off the shelf 
multimedia technology. This approach offers several advantages over those conventionally 
employed. Development time using this type of technology is dramatically reduced due 
primarily to its object-oriented nature, overall system environment, and extensive set of 
development tools available. The testing of the working prototype can be carried out 
throughout the development process to verify accuracy and program operation. Software 
and hardware acquisition and maintenance are both relatively inexpensive and easily 
attainable because of the use of off-the-shelf equipment and programs available 
commercially. The level of friendliness of the program greatly facilitates the acceptance by 
initial users, and the lack of a formal or complex query language significantly reduces 
training time. Lastly, because of the modular construction of the program, changes and 
revisions to individual elements are easily made and do not affect other modules within the 
program. 

Having the basic computer program completed, it will now be relatively simple for the 
continuation of development into the next rocket to be constructed. The most critical aspect 
of this development will be the acquisition of accurate and detailed costing and parts data 
from the contractors involved. Additionally, the development of a method to accurately 
track manhours for construction, design and development and those costs associated with 
these areas will be required. The tracking and optimization of cost and interface 
interactions will be critical to the SEALAR program's success. In conclusion, it has 
become evident that this can be accomplished both accurately and economically through the 
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employment of multi-media technology. This approach will contribute significandy to 
SEALAR's viability among the launch vehicles both in the inventory today as well as those 
on the drawing boards for tomorrow. 

As of the date of completion of this document, the SEALAR program remains in the 
proof of concept phase. Initial plans for a July 1991 launch of the proof of concept 
vehicle, the X-3 had to be scrubbed after an oxygen leak developed in the pressurized 
oxygen tank during a static test. Subsequently it was determined that all of the X-3’s tanks 
needed to be replaced. Plans now include the building of the X-3D, the follow-on rocket, 
and in its consturuction employ stainless steel tanks vice the maraging steel of those used in 
the X-3. 
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APPENDIX B 



DEVELOPERS SCRIPTS 

Script of Stack: "Argos 3:Desktop Folder: JFM:X3 Project" 



oo oo oo oooo oo oo oo oo oooo oo oooo oo oo oooo oooo oooo oo oooo oooo oooooooo oooo oo oooo oo oo oooo oo oo oooo oo oo oo oo 
oooooooooooooooooooooooooooooooooooooooooooooooo 

Script of Stack: X3 Project 

This script controls the overall operation of the SEALAR HyperCard 
program and stack 

OO OO OO OOOO OOOO OO OO OO OO oo OOOO OOOO OO OO OO OO OO OO OO OOOO OOOO OOOO OOOO OOOO OO OO OO OO OO OOOO OOOO OOOO OO OOOO OO 

oo oooo oooo oo oooo oo oo oo oo oo oo oo oo oo oo oo oo oo oo oo oo 



on openStack 
global mode 
set userlevel to 5 
end openStack 

on closestack 

— this handler will automatically compact stack 
if the freesize of this stack > 0.15 * the size of this stack then 
doMenu "Compact Stack" 
end if 

end closestack 
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on gohome 
play "BYE" 
end gohome 
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There are 2 Backgrounds in Stack: "X3 Project". 



Script of Background "GRAPHIC" 

oo oooo oooo oooo oooo oooo oo oooo oooo oooo oooooooo oooooo oooooooo oooo oooo oo oooo oooo oooooooooooo oo oooo oo 
oooooooooo oooooo oooooooooooooo oooooooooooooooooo 

Script of background: id 8104 Graphic 

This script resets the stack upon termination of the program, controls 
the synthetic voice simulation and controls the digitized voice segments 
employed during program operation. 

OO oooo oooo oooo oooo oooo oo oooo oooo oooo oooo oo oo oooooooooo oooo oooooooo oo oooo oooo oooo oooo oooooo oooooo 
oo oooo oooo oo oooooooo oooooo oooo oooooo oooooooooooo 



on closecard 

— this handler will automatically reset cards to original state 

— if field "Techman" is visible 

if visible of field "Techman" = true then 
set lockscreen to true 
hide field "Techman" 
repeat with i=l to the number of buttons 
show button i 
end repeat 

show background button "sorry" 
set lockscreen to false 
hide msg 
end if 

end closecard 
on SEALARTALK x 

-- this handler will speak in computer voice the text contained in 

— x. This procedure requires several TALK XCMD’s and MacinTalk 
-- must be in the system folder. 

if hilite of background button "VOICE" = true then 
TALK x, 160, 115 
end if 

end SEALARTALK 



on opencard 

— this handler will speak in computer voice the text conatined in 

— x. This procedure requires several TALK XCMD’s and MacinTalk 

— must be in the system folder. This procedure will be invoked 

— only if the individual card does not have an OpenCard Handler. 

—if hilite of background button "VOICE" = true then 

-TALK FIELD "Techman", 160, 115 
—end if 
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show card picture 
end opencard 

on re turnkey 

— this is a redefinition of the re turnkey function 

— for the purposes of automating the find string command 

— so the user may simply hit return in order to find the next 
-- occurence of a find string in both the techman field or 

-- the nomenclature field. HyperCard doesn’t support this without 

— a custom handler. 

if (char 1 to 1 1 of msg) = "find string" then 
put the id of this card into tempid 
if visible of field "Techman" then 
set lockscreen to true 
send retumKey to HyperCard 
if tempid o id of this card then 
go recent card 
hide card picture 

set visible of field ’Techman" to true 
repeat with i=l to the number of buttons 
hide button i 
end repeat 
end if 

set lockscreen to false 
else 

send retumKey to HyperCard 
end if 
else 

send retumKey to HyperCard 
end if 

end retumKey 



Script of Background "SEALAR BACKGROUND I" 



oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 
oo oooo oooo oo oooo oo oo oo oo oo oooo oooo oo oooo oooo oo 

Script of background: SEALAR BACKGROUND I 

This script defines the paramaters and voice qualities of the synthetic 

voice employed throughout the program 

OO OOOO OOOO OOOO OOOO OOOO OO OOOO OOOO OOOO OQOOOOOOOO oooo oooo oooo oooo oooo oo oooo oooo o ooo oooo oooo oo oooo oo 
oo oooo oooo oo oooo oooo oooo oo oooo oo oo oo oooo oooo oo 
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on S E AL ART ALK x 

— this handler will speak in computer voice the text contained in 

— x. This procedure requires several TALK XCMD's and MacinTalk 

— must be in the system folder. 

TALK x, 160, 115 

end SEALARTALK 
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There are 15 Cards in Stack: "ESCAP". 

Script of Card "SEALAR LOGO" 

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 
oooooo oooooo oooo oooo oooo oo oooo oooooo oooooooo oo 

Script of Card: SEALAR LOGO, id 2093 

The script opens the SEALAR LOGO card, welcomes the user to the SEALAR 
program and then utilizes the visual effect iris close to close the card. 

OO oooooooo oooo oooooooo oooooo oooo oooooooooooooo oooooooo oooo oooooooo oooooo oooo oooo oooo oooo oooooooo 
oooooo oooooo oooo oooooooo oo oooo oooooo oooo oooooo 



on openCard 

S E AL ART ALK "Welcome to see lar, offering cost efecteve access to space" 
visual effect iris close 
go next 
end openCard 



Script of Card "X3 Test Vehicle" 

oooooo oooo oooooo oooooo oooooo oooooooo oooo oooooo oooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooooo 
oooooooooo oooooo oooooooo oo oooooooooooooo oooooo 

Script of card: id 8720 X3 Test Vehicle 

This script opens X3 Test Vehicle card and controls the visual effects 
upon closing. 

OO OOOO OOOO OOOO OO OO OOOO OO OO OO OO OO OOOO OOOO OOOO OO OOOO OOOO OOOO OOOO OOOO OO OOOO OOOO OOOO OOOO OOOO OO OO OO OO 

oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 
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on openCard 

SEALARTALK "X 3 test vee hickle" 
wait 5 seconds 
go next 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 

Script of Card "X3 Subsystems" 

oooooo oooo oooo oooooooo oooooooooo oooooooo oooooo oooooooooooo oooooooo oooooooooo oooo oooo oooo oooooooo 
oo oooooooo oo oooo oooooooooooooo oooooo oooooooooo 

Script of card: id 4890 X3 Subsystems 

This script provides instructions to program user to enable selection of 
desired subsystem and controls visual effects. 

oooooo oooo oooo oooo OOOOOO OOOO OOOOOOOO OOOOOOOOOO OOOOOOOO OOOOOOOO OOOO OOOOOOOOOO oooo oooo oooo oooooooo 

oooooo oooo oooooo oooooooo oooooooooo oooooooooooo 



on openCard 

SEALARTALK "X 3 Sub systum break down - please select the desired, subsystum" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 
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Script of Card "Engine Cluster" 

oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooooo 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 

Script of Card: id 5173 Engine Cluster 

This script controls the synthetic voice simulation and the visual 

effects employed on the card. 

OO oooo oooo oooo oooo oooo oo oooooooo oooo oooo oooo oo oooo oooo oooo oooo oooo oo oooo oooo oooo oooo oooo oo oooo oo 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oooooo oooo oo 



on openCaxd 

SEALARTALK "Engin cluster Assemmbly" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 



Script of Card "Thrust Frame" 

OOOOOO oooo oooo OOOO OOOO OOOOO O oooo oooo oooo oooo OOOOOO oooo OOOOOOOO oooo oooooo oooo O OOO OOOO OOOO oooooooo 
oooooo oooo oooooo oooo oooo oo o ooo oooo oooooo oooooo 

Script of card: id 5853 Thrust Frame 

This script controls operation of synthetic voice and visual effects 
employed on the card. 

oo oooo oooo oooo oo oo oo oo oo oooo oooo oooo oooo oooo oo oooo OOOO OOOO OOOO OOOO OO OOOO OOOO OOOO OOOO oo oo oo oooo oo 

oooooo oooo oo oooo oooo oooo oo oooo oooo oooooo oooo oo 
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on openCard 

SEALARTALK "Thrusst frame, specefickationns" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 



Script of Card "LR 101 Engine" 

oo oooooooo oooooooo oooooooooo oooooooooooooooooo oooooooooooo oooooooo oo oooooooo oooooooooooo oo oooo oo 
oooooooooooooooooooooooooooooooooooooooooooooo 

Script of card: id 2791 LR 101 Engine 

This script controls the synthetic voice and visual effects employed on 
the card. 

OOOOOOOOOO OOOO OOOOOOOOOO OOOOOOOOOOOO OOOOOOOOOO OOOOOOOOOOOO OOOO OOOOOOOOOO OOOOOOOO OOOO OOOO OOOOOOOO 

oooooooooo oooooooooo oooo oooooooooo oooooooooooo 



on openCard 

SEALARTALK "Rocket dine, L R 1 O 1 Engin" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 
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Script of Card "Rocket Center Section" 



oo oooooooo oooo oooo oooooo oooooooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooooo 
oo oooooooooo oooo oooo oooooo oooooooo oooooo oooooo 

Script of card: id 6376 Rocket Center Section 

This script controls the synthetic voice and visual effects employed on 

the card. 

oooooo oooo oooo OOOOOOOO OOOOOO oooooooo oooo oooooo oooo oooooooo oooooooo oooooo oooo oooo oooo oooo oooooooo 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 



on openCard 

SEAL ART ALK "Rocket center section, specifecationns" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 



Script of Card "Rocket Fuel Tank" 



oo oooo oooo oo oooo OOOO OOOO oo OOOO oooo oo oooo oooo oo 

Script of card: id 6936 Rocket Fuel Tank 

This script controls the synthetic voice and visual effects employed on 
the card. 
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oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooooo 



oooooooooooooooooooooooooooooooooooooooooooooo 



on openCard 

SEALARTALK "Rocket fuull tank, specifecationns" 
end openCard 

on close Card 
visual effect iris close 
end closeCard 



Script of Card "Rocket Oxygen Tank" 

oooooo oooo oooo oooo oooo oooooooooo oooooooooooooooooooooooooo oooooooo oooooo oooo oooo oooo oooooooooooo 
oooooooooooooooooooooooooooooooooooooooooooooo 

Script of card: id 7530 Rocket Oxygen Tank 

This script controls the synthetic voice and visual effects employed on 

the card. 

OOOOOO OOOO OOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOO OOOO OOOOOO OOOO OOOO OOOO OOOO OOOOOOOO 

oooooo oooo oooooo oooo oooo oooooo oooo oooooo oooooo 



on openCard 

SEALARTALK "Rocket oxygen tank, specifecationns" 
end openCard 
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on closeCard 



visual effect iris close 
end closeCard 



Script of Card "Launch Support Equipment" 

oooooooooooooooo o ooooooooooo o ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

oooo o ooooooooooooooooooooooooooooooooooooooooo 

Script of card: id 8576 Launch Support Equipment 

This script controls the synthetic voice and visual effects employed 

on the card. 



oo oooo oooo oooo oo oo oooo oo oooo oooo oooo oooo oooo oo oooo oooo oooo oooo oooo oo oooo oooo oooo oooo oooo oo oooo oo 
oo oooo oooo oo oooo oooooooooooooo oooo oooooooooo oo 



on openCard 

SEALARTALK "Launch support equipment, design presently under revision" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 
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Script of Card "Avionics/Payload" 



oo oooooooo oooo oooo oooooo oooo oooo oooo oooooooooo oooooooo oooooooooooo oooooooooo oooooooooooo oo oooo oo 
oooooooooooooooooooooooooooooooooooooooooooooo 



Script of card: id 7766 Avionics/Payload 

This script controls the synthetic voice and visual effects employed 

on the card. 



OOOOOO oooo oooooooo oooo oooooo oooo oooooooooooooo oooooooooooo oooooooooo oooo oooo oooooooo oooooo oooooo 
oooooo oooo oooooooooo oooo oooooo oooo oooooooooooo 



on openCard 

SEALARTALK "Avey onics, and payload" 
end openCard 



on closeCard 
visual effect iris close 
end closeCard 

Script of Card "RF Deck Layout" 

oo oooo oooooooo oooo oooo oooooooooo oooooooo oooooo oooooooo oooooooo oooo oo oooooooo oooo oooo oooooo OOOO OO 
OO OOOOOOOO OO OOOO oooo oooo oooooo oooooo oooo oooooo 

Script of card: id 9162 RF Deck Layout 

This script controls the synthetic voice and visual effects employed 
on the card. 
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oo oooo oooo oooooooo oooooo oooo oooo oooo oooooooooo oooooooo oooo oooooooooo oooo oooo oooo oooo oooo oooooo oo 



oo oooo oooo oo oooooooo oooo oo oooo oooo oooooo oooo oo 



on openCard 

SEALARTALK "R F deck, lay out" 
end openCard 



on closeCard 
visual effect iris close 
end closeCard 



Script of Card 'Telemetry Deck" 

OOOOOO oooo oooo oooo oooo oooooo oooooooo oooooooo oooooooooo oooo oooo OOOO oooooo oooo oooo oooo OOOO OOOOOOOO 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 

Script of card: id 9986 Telemetry Deck 

This script controls the synthetic voice and visual effects employed on 
the card. 

oooooo oooo oooo oooo oooo oooooooooo oooo oooo oooooo oooo oooo oooo oooo oooo oooooo oooo oooo oooo oooo oooooooo 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 



on openCard 

SEALARTALK "Telem ettry, deck, lay out" 
end openCard 



on closeCard 



visual effect iris close 
end closecard 



Script of Card "Battery Deck" 

oo oooo oooo oooo oooo oooooooooooooooooooooooooooooooooooooooooooo oooo oo oooo oooo oooooooo oooo oo oooo oo 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 

Script of card: id 10249 Battery Deck 

This script controls the synthetic voice and visual effects employed on 
the card. 

OO oooo OOOO OOOO OOOO OOOO oooooooooooooo OOOO oooo OO oooo OOOO oooo OOOO OOOO OO OOOO OOOO OOOO oooooooooo oooo OO 
oo oooo oooo oo oooo oooo oooo oo oooo oooo oo oooo oooo oo 



on openCard 

SEALARTALK "Batt tery, deck, lay out" 
end openCard 

on closeCard 
visual effect iris close 
end closeCard 



Script of Card "Interface Relationships" 

OO OOOO oooo OOOO OOOO oooo OOOOOOOOOOOOOO OOOO OOOOOOOOOOOOOO oooo oooo OOOOOOOOOO oooo oooo oooo oooo OO OOOO OO 

oo oooo oooo oo oo oo oooo oooo oo oooo oooo oo oooo oooo oo 

Script of card: id 1 1402 Interface Relationships 

This script controls the synthetic voice and visual effects employed on 

the card. 
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oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

oooooooooooooooooooooooooooooooooooooooooooooo 



on openCard 

SEALARTALK "First level interface relationship description" 
end openCard 

on close Card 
visual effect iris close 
end closeCard 
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There are 6 Background Fields on Background "GRAPHIC". 

Script of Background Field X3 Test Vehicle of Background GRAPHIC 



on mouseUp 

go to card "X3 SUBSYSTEMS" 
end mouseUp 



Script of Background Field BUTTONS of Background GRAPHIC 



on mouseup 
GLOBAL CARDID 

put CARDID into SECOND ITEM OF line— > 

(clicklineO) of field "DATA" 

SET VISIBLE OF FIELD "BUTTONS" TO FALSE 
show card picture 

REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
set visible of button COUNT to true 
END REPEAT 
end mouseup 



Script of Background Field data of Background GRAPHIC 



- EACH LINE NUMBER OF THE FIELD CONTAINS TWO DATA ITEMS WHICH 

- CORRESPOND TO A BUTTON NUMBER. I.E. LINE 1 CONTAINS DATA FOR 
BUTTON 12 

-- THE FIRST ITEM IS THE CARD ID OF THE CHILD OF THIS ITEM 

- THE SECOND ITEM IS THE CARD ID OF THE CARD IN THE STACK WHICH 

- CORRESPONDS TO THIS ITEM 



Script of Background Field Techman of Background GRAPHIC 
on mouseup 

-- this handler turns show field "description" off and on 
- show the card picture with associated buttons on. 

lock screen 
show card picture 

set the highlight of background btn "VOICE" to true 
set visible of field "Techman" to false 
repeat with i=l to the number of buttons 
show button i 
end repeat 

repeat with i=l to the number of cd buttons 
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show cd button i 
end repeat 

repeat with i=l to the number of cd fields 
show cd fid i 
end repeat 
lock screen 

end mouseup 



There are 0 Background Fields on Background "SEALAR BACKGROUND I". 



There are 0 Card Fields on Card "SEALAR LOGO" 



There are 1 Card Fields on Card "X3 Test Vehicle" 
There are 8 Card Fields on Card "X3 Subsystems" 



Script of Card Field "card field id 3" of Card "X3 Subsystems" 



on mouseUp 

go to card "Engine Cluster" 
end mouseUp 



Script of Card Field "card field id 4" of Card "X3 Subsystems" 



on mouseUp 

go to card "ROCKET OXYGEN TANK" 
end mouseUp 



Script of Card Field "card field id 5" of Card "X3 Subsystems" 



on mouseUp 

go to card "ROCKET CENTER SECTION" 
end mouseUp 



Script of Card Field "card field id 6" of Card "X3 Subsystems" 



on mouseUp 

go to card "ROCKET FUEL TANK" 
end mouseUp 



Script of Card Field "card field id 8" of Card "X3 Subsystems" 



on mouseUp 

go to card "AVIONICS/PAYLOAD" 
end mouseUp 
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Script of Card Field "card field id 9" of Card "X3 Subsystems" 
on mouseUp 

SEALARTALK "RECOVERY SUBSYSTUM PRESENTLY NOT MOD ELLED" 
go to card "RECOVERY SUBSYSTEM" 
end mouseUp 

There are 2 Card Fields on Card "Engine Cluster" 

There are 1 Card Fields on Card "Thrust Frame" 

There are 0 Card Fields on Card "LR 101 Engine" 

There are 1 Card Fields on Card "Rocket Center Section" 

There are 1 Card Fields on Card "Rocket Fuel Tank" 

There are 1 Card Fields on Card "Rocket Oxygen Tank" 

There are 1 Card Fields on Card "Launch Support Equipment" 

There are 0 Card Fields on Card "Avionics/Payload" 

There are 0 Card Fields on Card "RF Deck Layout" 

There are 0 Card Fields on Card "Telemetry Deck" 

There are 0 Card Fields on Card "Battery Deck" 

There are 0 Card Fields on Card "Interface Relationships" 

There are 15 Background Buttons on Background "GRAPHIC". 

Script of Background Button "Techman" of Background "GRAPHIC" 

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

oooooooooooooooooooooooooooooooooooooooooooooo 

Script of background button: id 4 Techman 

This script controls the transition between the HyperCard stack and the 
text reference, allowing the user to obtain technical information 
with minimal effort 
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oo oooo oooo oooo oooooooo oo oooo oooooooo oooo oooo oo oooo oooo oooo oooooooo oo coco oooo oooo oooo oooo oo oooooo 



oo oooooooo oooooo oooooooo oooooo oooo oo oooooooo oo 



on mouseUp 

-- this handler toggles between showing field "Techman” and 
-- showing the card picture with associated buttons. 

PLAY "TECHMAN" 

if visible of field "Techman" = true then 
Lock Screen 

set the highlight of background btn "VOICE" to true 
hide field "Techman" 
show card picture 
set scroll of field "Techman" to 1 
repeat with i=l to the number of buttons 
show button i 
end repeat 

repeat with i=l to the number of cd buttons 
show cd button i 
end repeat 

repeat with i=l to the number of cd fields 
show cd fid i 
end repeat 
unlock screen 

else 

lock screen 
hide card picture 
show field "Techman" 
set scroll of field "Techman" to 1 
repeat with i=l to the number of buttons 
hide button i 
end repeat 

repeat with i=l to the number of cd buttons 
hide cd button i 
end repeat 

repeat with i=l to the number of cd fields 
hide cd fid i 
end repeat 
Unlock screen 



end if 

end mouseUp 
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Script of Background Button "Cost" of Background "GRAPHIC 



on mouseUp 

open "X3-Spreadsheet" with "Microsoft Excel 3.0" 
end mouseUp 



Script of Background Button "HELP" of Background "GRAPHIC" 



on mouseUp 
PLAY "HELP" 
push this card 

go to stack "SEALAR HELP" 
end mouseUp 



Script of Background Button "Previous Card" of Background "GRAPHIC" 



on mouseUp 

— goes back to previous view level 
visual effect iris close 
go back 
end mouseUp 



Script of Background Button "UP" of Background "GRAPHIC" 

on mouseUp 
-- goes up the hierarchy 
-visual effect zoom out 
-go to card id field "Uplink" 
visual effect iris close 
GO TO CD "X3 Subsystems" 
end mouseUp 



Script of Background Button "Find" of Background "GRAPHIC" 



oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 

oooooooooooooooooooooooooooooooooooooooooooooo 

Script of button: id 30 Find 

This script controls the operation of the modified search for the desired 
string through the field "Techman." 



72 



oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 



oo oooo oooo oo oo oo oooo oo oo oo oooo oooo oo oo oo oooo oo 



on mouseUp 

— this handler provides for a modified search. 

put the id of this card into tempid 

PLAY "SEARCH" 

ask’Tlease enter Search String." 

put it into Goal 

if visible of field "TECHMAN" then 
set lockscreen to true 

set the highlight of background btn "VOICE" to false 

put "find string" && quote & Goal & quote && "in field Techman "— 1 

into msg 

hide msg 

send retumkey to hypercaid 
if tempid o id of this card then 
go recent 

set the highlight of background btn "VOICE" to true 
set lockscreen to false 
end if 
else 

lock screen 
hide card picture 
show field "Techman" 
set scroll of field "Techman" to 1 
repeat with i=l to the number of buttons 
hide button i 
end repeat 

repeat with i=l to the number of cd buttons 
hide cd button i 
end repeat 

repeat with i=l to the number of cd fields 
hide cd fid i 
end repeat 
Unlock screen 

hide msg 

put "find string" && quote & Goal & quote && "in field TECHMAN" into msg 
hide msg 

send retumkey to hypercard 
end if 

end mouseUp 
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Script of Background Button "LIBRARY" of Background "GRAPHIC" 



on mouseUp 
PLAY "LIBRARY" 
push card 

go to card library OF STACK "SEALAR" 
end mouseUp 



Script of Background Button "EXIT" of Background "GRAPHIC" 



on mouseUp 
gohome 
go home 
end mouseUp 



Script of Background Button "PRINT" of Background "GRAPHIC" 



on mouseUp 
play "PRINT" 
doMenu Print Card 
end mouseUp 



Script of Background Button "GRAPHICS REWRITE" of Background "GRAPHIC" 



on mouseup 

REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
set the script of button COUNT to-i 

Graphic Handler may be found in this cards background"-! 

& return & "On MouseUp" & return &-i 
"GRAPHIC (number of me)" & return & "end MouseUp" 
end repeat 
end mouseup 



Script of Background Button "VOICE" of Background "GRAPHIC" 



on mousedown 
-- toggles voice on/off 
if the hilite of me then 
SEALARTALK "VOICE ONN" 
else 

TALK "VOICE OFF", 160, 115 
end if 

end mousedown 



Script of Background Button "INSERT PARTNUMBER" of Background "GRAPHIC" 
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on mouseUp 

GLOBAL BUTTONN AME 
GLOBAL CARDID 
PUT EMPTY INTO BUTTONNAME 
PUSH CARD 

ASK "INPUT PARTNUMBER" 

GOTOSTACKCOSAL 

FIND IT IN FIELD "PART NUMBER" 

PUT SHORT ID OF THIS CARD INTO CARDID 
POP CARD 
hide card picture 

REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
set visible of button COUNT to false 
END REPEAT 

IF FIELD "BUTTONS" IS EMPTY THEN 
REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
PUT ((short name of CARD BUTTON COUNT) & "," & COUNT-. 
& RETURN) AFTER FIELD "BUTTONS" 

END REPEAT 
END IF 

ANSWER "PLEASE SELECT BUTTON NAME" 

SET VISIBLE OF FIELD "BUTTONS" TO TRUE 
end mouseUp 



Script of Background Button "NONE,NONE" of Background "GRAPHIC" 



on mouseUp 

ANSWER "ARE YOU SURE" 

IF IT <> "OK" THEN EXIT MOUSEUP 

REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
PUT "NONE, NONE" INTO LINE COUNT OF FIELD "DATA" 
END REPEAT 
end mouseUp 



Script of Background Button "SOMETHING, NONE" of Background "GRAPHIC" 



on mouseUp 

ANSWER "ARE YOU SURE" 

IF IT <> "OK" THEN EXIT MOUSEUP 
REPEAT WITH COUNT = 1 TO NUMBER OF CARD BUTTONS 
PUT (CHAR 17 TO 25 OF LINE 4 OF THE SCRIPT OF BUTTON COUNT)-. 
& ", NONE" INTO-n 
LINE COUNT OF FIELD "DATA" 

END REPEAT 
end mouseUp 



Script of Background Button "Interface" of Background "GRAPHIC" 
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on mouseUp 

go to card "Interface Relationships" 
end mouseUp 



There are 0 Background Buttons on Background "SEALAR BACKGROUND I". 



There are 0 Card Buttons on Card "SEALAR LOGO". 



There are 0 Card Buttons on Card "X3 Test Vehicle". 



There are 7 Card Buttons on Card "X3 Subsystems". 



Script of Card Button "Engine Section" of Card "X3 Subsystems" 



on mouseUp 

go to card "Engine Cluster" 
end mouseUp 



Script of Card Button "Avionics/Payload" of Card "X3 Subsystems" 



on mouseUp 

go to card "AVIONICS/PAYLOAD" 
end mouseUp 



Script of Card Button "Recovery Subsection" of Card "X3 Subsystems" 



on mouseUp 

SEALARTALK "RECOVERY SUBSYSTEM PRESENTLY NOT MODELLED" 
go to card "RECOVERY SUBSYSTEM" 
end mouseUp 



Script of Card Button "Fuel Tank" of Card "X3 Subsystems" 



on mouseUp 

go to card "ROCKET FUEL TANK" 
end mouseUp 



Script of Card Button "Helium Tank" of Card "X3 Subsystems" 



on mouseUp 



76 



go to card "ROCKET CENTER SECTION" 
end mouseUp 



Script of Card Button "Oxidizer Tank" of Card "X3 Subsystems" 



on mouseUp 

go to card "ROCKET OXYGEN TANK" 
end mouseUp 



Script of Card Button "Launch Support " of Card "X3 Subsystems" 



on mouseUp 

go to card "LAUNCH SUPPORT EQUIPMENT" 
end mouseUp 



There are 3 Card Buttons on Card "Engine Cluster". 

Script of Card Button "Propulsion Valve" of Card "Engine Cluster" 



—on mouseUp 
— goes up the hierarchy 
—visual effect zoom out 
—go to card id field "Uplink" 

—end mouseUp 
-on mouseUp 

go to card "PROPULSION VALVE" 

-end mouseUp 
on mouseUp 

SEALARTALK "PRO PULSION VAALLVE PRESENTLY NOT MOD ELLED" 

go to card "RECOVERY SUBSYSTEM" 
end mouseUp 



Script of Card Button "Thrust Frame" of Card "Engine Cluster" 



-on mouseUp 
- goes up the hierarchy 
visual effect zoom out 
go to card id field "Uplink" 

—end mouseUp 
on mouseUp 

go to card "THRUST FRAME" 
end mouseUp 



Script of Card Button "Engine Assembly" of Card "Engine Cluster" 



-on mouseUp 
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- goes up the hierarchy 
visual effect zoom out 
go to card id field "Uplink" 
--end mouseUp 
on mouseUp 

go to card "LR 101 ENGINE" 
end mouseUp 



There are 0 Card Buttons on Card "Thrust Frame". 



There are 0 Card Buttons on Card "LR 101 Engine". 



There are 0 Card Buttons on Card "Rocket Center Section". 



There are 0 Card Buttons on Card "Rocket Fuel Tank". 



There are 0 Card Buttons on Card "Rocket Oxygen Tank". 



There are 0 Card Buttons on Card "Launch Support Equipment". 



There are 3 Card Buttons on Card "Avionics/Payload". 



Script of Card Button "RF Deck" of Card "Avionics/Payload" 



on mouseUp 

go to card "RF Deck Layout" 
end mouseUp 



Script of Card Button "Telemetry Deck" of Card "Avionics/Payload" 



on mouseUp 

go to card "Telemetry Deck" 
end mouseUp 



Script of Card Button "Battery Deck" of Card "Avionics/Payload" 



on mouseUp 
go to card "Battery Deck" 
end mouseUp 



There are 0 Card Buttons on Card "RF Deck Layout". 
There are 0 Card Buttons on Card "Telemetry Deck". 
There are 0 Card Buttons on Card "Battery Deck". 
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There arc 1 Card Buttons on Card "Interface Relationships". 

Script of Card Button "1L Interface Spreadsheet" of Card "Interface Relationships 



on mouseUp 

open "1L Interface" with "Microsoft Excel 3.0" 
end mouseUp 
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APPENDIX C 



X3 VEHICLE DESCRIPTION 



The X3 rocket vehicle has been designed primarily to serve as a test vehicle to 
demonstrate the water launch and recovery of reusable pressure fed liquid fueled rockets. 
The X3 rocket is a relatively simple stored gas pressure fed liquid fueled propulsion design 
(Huzel and Huang, 1971). Pressure fed designs are generally simpler and more reliable 
than turbopump designs as the turbopump itself is generally quite complex. On the other 
hand, in pressure fed designs, the fuel and oxidizer tanks must be stronger to withstand the 
ullage pressure. Correspondingly these tanks are thicker and heavier. The stronger tanks 
provide some synergistic advantages in simplifying the recovery process and generally 
making the rocket less susceptible to handling damage. 



X3 vehicle specification: 

Height 

Diameter 

Launch weight 

Burnout weight 

Engine thrust 

Engine type 

Bum time 

Fuel 

Oxidizer 

Fuel and LOX feed 

Fuel and LOX tank material 

Guidance 



276 in 
25 in 
30001b 
10001b 
4000 lb 

4 Rocketdyne LR-101 
114 sec 
Kerosene 
Liquid oxygen 
Helium pressurization 
Vasco 250 maraging steel 
Strapdown inertial 



Structure: 

Fuel and oxidizer tank weights are a significant issue in a pressure fed rocket. 
Composite materials, cryostretched steel and maraging steel are prime candidates for the 
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tanks in terms of strength to weight ratios although relatively little is known about the 
associated cryogenic properties. Composite materials have provided the highest strength to 
weight ratios to date although cryogenic characteristics are virtually unknown. Further 
investigation of both composite materials and cryostretched steel tankage is planned in other 
phases of the SEALAR program. 

Maraging steel, as used for both the X3 vehicle fuel and oxidizer tanks, provides an 
excellent strength to weight ratio. In addition to containing the pressurized fuel and 
oxidizer, the tanks also serve as the primary vehicle structure. The tanks have held up well 
in a series of helicopter drop reentry simulation tests. Some stress corrosion has been 
observed in test samples. 

The X3 rocket fuel is kerosene. The oxidizer is liquid oxygen (LOX). This 
combination is both relatively low cost and easy to handle. The RP-1 fuel and LOX tanks 
form the basic rocket structure. Both tanks are pressurized to 600 psi by gaseous helium 
supplied from a titanium pressure vessel. The pressurized RP-1 kerosene is also used as a 
hydraulic fluid for the thrust vector control (TVC) system. 

Propulsion subsystem: 

Helium is stored in a high pressure titanium sphere in a chilled gaseous form providing 
a 5-to-l tankage weight saving over the equivalent ambient temperature storage. The X3 
helium tank contains 29.8 pounds of helium at 160* R which is pressurized to 3250 psi 
from ground service prior to launch. The helium tank outlet is connected to a series of heat 
exchangers. A much higher ullage mass utilization can be achieved by preheating the 
helium. Additionally, downstream pneumatic components need not withstand cryogenic 
temperatures. The heat is exchanged with the kerosene fuel flowing to the engines. The 
heat exchanger outlet is connected to a helium pressure regulator which regulates the helium 
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pressure to 600 psi. The helium regulator used in the X3 vehicle was originally developed 
for use as part of the Agena spacecraft attitude control system. A relief valve located on the 
regulator protects the vehicle from overpressure in case of a regulator failure. The regulator 
outputs are passed through pressurize/vent valves to the kerosene and LOX tanks. To 
further minimize the helium tank size and weight, the rocket is initially pressurized from a 
ground-based helium supply. 

The fuel tank, containing 685 pounds (100 gallons) of RP-1 kerosene jet fuel, is 
pressurized to 600 psi by the vehicle helium subsystem. The fuel tank is manufactured out 
of 0.060 inch thick Vasco 250 maraging steel to provide a high strength to weight ratio. A 
capacitive sensor within the tank provides a measure of the fuel load within the tank. The 
LOX tank is located aft of the fuel tank to minimize the length of the cryogenic LOX 
plumbing. The rearward LOX tank position however somewhat reduces the vehicle 
dynamic stability. The RP-1 tank outlet is connected to the engines through a pneumatically 
operated Emergency Fuel Valve (EFV) and the helium heat exchanger. The pressurized 
RP-1 is also used to operate the thrust vector control servovalves. 

The LOX tank, containing 1294 pounds (140 gallons) of liquid oxygen, is pressurized 
to 600 psi by helium in a manner similar to the fuel tank. The LOX tank is manufactured 
from 0.060 inch thick Vasco 250 maraging steel which provides the required strength to 
weight ratio. A capacitive sensor within the tank provides a measure of the LOX load 
within the tank. The LOX tank outlet is connected to a Propellant Control Valve (PCV). 
The PCV modulates the LOX flow rate in order to insure a simultaneous fuel and LOX 
burnout. The PCV position is controlled from a signal generated by the relative difference 
between the fuel and LOX tank level sensors. 

Both the fuel and LOX tanks feed a cluster of four Rocketdyne LR-101 engines 
providing a total of 4000 pounds of sea level thrust. The LR-101 engines were originally 
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used for vernier steering of the Atlas, Delta and Thor launch vehicles. In the X3 vehicle, 
each engine is pivoted along one axis. The cluster of 4 gimballed engines provide complete 
yaw, pitch and roll control. The engines are operated at a relatively low chamber pressure 
of 360 psi. 



Engines: 

The Rocketdyne LR-101 engines are regeneratively cooled by passing the fuel through 
the nozzle and throat regions prior to thrust chamber injection. 



Rocketdyne LR-101 rocket engine specifications (single chamber): 



Propellants: 



Oxidizer Liquid Oxygen (LOX) 

Fuel RP-1 (Kerosene) 



Thrust chamber physical characteristics: 



Combustion chamber 



Diameter 2.73 in 

Volume 41.76 in^ 

Area 5.86 in^ 

Characteristic length 20.00 in 

Contraction 1/2 angle 15 degrees 

Expansion 1/2 angle 15 degrees 
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Nozzle: 



Throat diameter 1 .63 in 

Exit diameter 3.87 in 

Expansion ratio 5.622 : 1 

Throat area 2.088 in 2 

Exit area 11.74 in 2 

Weight (approx) 12.0 lb 



Steady state performance: 



Thrust (sea level) 

Thrust (vacuum) 

Specific impulse (Isp) 

Chamber pressure 

Mixture ratio 

Fuel flow rate 

Oxidizer flow rate 

Characteristic velocity (C*) 

Thrust coefficient 

Thrust coefficient 

Injector pressure drop 



1007.5 lbf 
1180.4 lbf 

205.4 sec'* 

360.0 psi 
1.9:1 

L692 lb/sec 
3.214 lb/sec 
4930. ft/sec 

1.340 (sea level) 
1.570 (vacuum) 
275. psid 



The LR-101 engines are started by pressurizing the fuel and LOX tanks, firing an 
igniter in each engine, verifying correct igniter operation and opening the EFV and LOX 
valves. 

The engines are ignited by a set of pyrotechnic igniters inserted into each engine throat. 
Each igniter is a single shot device using a solid propellant charge of hydroxyl-terminated 
polybutadiene, ammonium perchlorate plus magnesium. The charge is ignited using a 
standard Atlas electric match coupled through a BKN03 tablet. The entire charge is 
contained within the phenolic tube. The flame exits through opposing vents directly into the 
thrust chamber. The igniter is held in the thrust chamber by an aluminum spider bracket. 

Correct igniter operation is verified by a thermocouple attached to each igniter. It is 
imperative that all igniters are burning prior to the start of fuel and LOX flow or a hard start 
may result. A hard start is an explosion internal to an engine caused by an external flame 
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source propagating rearward into the engine. A hard start may result in a substantial 
overpressure which can permanently damage the engine. The igniter is ejected 
approximately 1/2 second after the engine start when the aluminum spider melts. 

After engine burnout, the propellant valve is closed to retain helium pressure to 
enhance the fuel and LOX tank strength during reentry. Engine burnout is identified by 
monitoring the thrust chamber pressure. Burnout is at 180 psi corresponding to 50% of 
nominal chamber pressure. Residual pressure in the tanks strengthens them during water 
impact. After landing, the tanks are vented (made safe) either by an RF command or 
manually. 

The smaller propulsion system valves are directly controlled by electrical solenoids. 
The larger valves such as the EFV and LOX valves are operated by helium pneumatic 
pressure using small solenoid pilot valves for control. Pressure transducers are installed on 
the helium, fuel and LOX tanks. An additional pressure transducer is installed on one 
engine to monitor chamber pressure during flight. 

During the static test firing phase, additional transducers are included. Examples of 
additional transducers include fuel and LOX flow rates, chamber pressures for all engines 
and helium heat exchanger temperatures. 

Thrust vector control: 

The rocket steering is controlled by a Thrust Vector Controller (TVC). Each of the four 
LR-101 rocket engines can be swiveled on one axis by a hydraulic actuator. The engine 
swivel range is 10 degrees, providing a maximum two-engine lateral control thrust of 350 
pounds. When opposite engine pairs are moved together, yaw or pitch control are obtained. 
Roll control is obtained by moving opposite pairs differentially. The command signals to 
the TVC originate in the Flight Control Computer (FCC). 
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The actuators are controlled by Moog proportional servo valves. The pressurized fluid 
for the hydraulic actuators is RP-1 rocket fuel supplied directly from the fuel tank at 575 
psi. No boost pumps are used. The servo valve output is dumped overboard. The actuator 
position is sensed by a Linear Voltage Differential Transformer (LVDT) and signal 
conditioner assembly providing a voltage proportional to engine gimbal angle. The LVDT 
is rugged and well protected from saltwater effects. 

A servo controller compares the FCC commands with the LVDT sensed actuator 
positions. The error signal is used to control the servo valve so as to null the position error. 
The small signal bandwidth is 18 Hz because of the low hydraulic pressure, the system 
becomes slew rate limited (130/sec) with a 4.5 Hz large signal bandwidth (Witham, 1990). 

The maximum yaw and pitch thrust is limited to approximately 350 pounds by a 10 
degree gimbal angle. The lateral thrust is converted into a moment as a function of distance 
between the engines and the time varying center of gravity location. If the vehicle reaches a 
sufficiently high angle of attack (a) at a high dynamic pressure (q), an insufficient control 
authority may allow the rocket to become unstable. Typically, the most critical flight regime 
is in the peak dynamic pressure (max q) region, near 30,000 ft. In this region, the angle of 
attack is limited to approximately 5 degrees. Substantial wind shears induced by jet streams 
are common at this altitude. Because of an unacceptable control authority, small fins have 
been added near the tail to shift the center of pressure rearward. 

Recovery system: 

The X3 rocket is recovered after use by a pair of parachutes. At 10,000 feet, a drogue 
parachute is deployed by a drogue gun controlled by the FCC. The drogue parachute is an 
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8 foot diameter Kevlar hemi-flo design manufactured by Paranetics. This Kevlar drogue 
parachute was initially designed for a different version of the X3 rocket which required a 
very high altitude drogue parachute deployment. 

In this version of the X3, the drogue parachute is used to provide the initial 
deceleration, extract the main chute and for propellant settling in certain abort situations. 



— 

During an abort, the drogue parachute i » -ear of 

the rocket The fuel and LOX settling is owing 

a dump through the engine. In order t nd the 

LOX is dumped overboard first. Later. imped 

overboard. 

The main parachute is deployed at lute is 

used to extract the main chute from a c achute 

i' u 



is disreefed to a diameter of 46 feet. The rocket enters the water tail first at 32 feet per 
second. The fuel and LOX tanks are pressurized at water entry to provide additional 
strength. 

After landing, a radio beacon, dye marker and flashing light assist in locating the 
vehicle. 

X3- vehicle weight summary (10/10/901: 

Primary tank structure 344.0 

Fuel tank 

Center section structure 
Helium tank 
LOX tank 

Instrument bulkhead 
Oxygen subsystem 



Pressure vent valve 1.25 

Tank level sensor probe 3.5 

Plumbing, wiring, misc 3.25 
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Fuel subsystem 

Pressure / vent valve 1.25 

Tank level sensor probe 3.0 

Plumbing, wiring, misc 5.0 

Engine section 

Engine assembly 75.5 

Egg crate 18.5 

Instrumentation 10.0 

4 Jacket flowmeters 00.8 

4 Flex lines 2.0 

4 TVS actuators 7.2 

Raceway assembly 

4 Helium heat exchangers 15.0 

4 Raceway covers 12.0 

Wiring 5.0 

Drag bags 

4 Drag bags 12.0 

Drag bag packing 20.0 

Fins 15.0 

Center section assembly 

4 Prop utilization / emerg valves 3.0 

2 PU solenoid valves 2.5 

Helium regulator 4.0 

3/4" check valve 4.0 

LOX pressure / vent pilot valve 1.25 

Fuel pressure / vent pilot valve 1.25 

LOX tank overpressure switch 1.0 

Fuel tank overpressure switch 1.0 

Helium tank pressure transducer 1.0 

Fuel tank pressure transducer 0.75 

LOX tank pressure transducer 0.75 

Helium relief valve 0.25 

3 Temperature probes 0.25 

Plumbing, wiring, misc 8.0 
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Nose section 



Outer skin 26.0 

Locking ring 7.5 

Locking ring seal 1.0 

Main parachute 24.5 

Drogue parachute 4.5 

Drogue chute release & mortar 12.5 

Drogue chute skin 2.5 

Ring bulkhead and seal 3.0 

Honeycomb floor 5.0 

Recovery beacon 4.0 

Dye marker 1.0 

Plumbing, wiring, misc 15.0 

Avionics /payload 266.45 



Fluids 



Helium 29.8 

Residual fuel 14.0 

Residual LOX 0.0 

Burnout weight 1000.0 

Useable fuel 685.0 

Useable LOX 1294.0 

Launch weight 2979.0 
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APPENDIX D 

COST ANALYSIS SPREADSHEETS 
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